The frame buffer in OpenGL contains more than color values. Logically, there are also ancillary (or helper) buffers that hold per-pixel information in the depth, stencil, accumulation, alpha, and auxiliary buffers. And as the section on the display stage discussed, there may be multiple color buffers for double buffering (left, right) and stereo (front, back). As long as the minimum GLX requirements for OpenGL's frame buffer functionality are met, an implementation may support a wide variety of frame buffer configurations with varying buffers and number of bit planes.
These ancillary buffers may be provided by the graphics hardware, usually in dedicated graphics memory. The alternative is for the host to allocate these buffers from host memory.
Some per-fragment operations affect ancillary buffers (like the depth test) while some like the scissor test do not use ancillary buffers. The per-fragment operations form a pipeline as shown in Figure 4. The operations that are most expensive are those that require an ancillary buffer read-modify-write like the depth buffer and stencil tests.
Figure 5: Example of a triangle being rasterized into a frame buffer
using a 20-way image processor configuration.
Performing per-fragment operations is particularly parallelizable since each fragment's pixel update operations can be performed independent of other updates to different pixels. An effective technique for accelerating pixel updates is replication of numerous pixel processors, each processor updating a subset of the screen's pixels. Figure 5 shows an example of how 20 pixel processors might be utilized to parallelize fragment processing.
There are cost-performance limits to replicating pixel processors. Imagine if every pixel on the screen had its own pixel processor. Because most pixels are not being updated at any given moment in time and many polygons tend to be small (less than 40 pixels or so), most of the screen's pixel processors would be under-utilized, so the approach would likely not be cost effective.